1. Field of the Invention
The present invention generally relates to managing data abstraction models and, more particularly, to managing relationships in a data abstraction model abstractly describing data in a database.
2. Description of the Related Art
Databases are computerized information storage and retrieval systems. The most prevalent type of database is the relational database, a tabular database in which data is defined so that it can be reorganized and accessed in a number of different ways. A distributed database is one that can be dispersed or replicated among different points in a network. An object-oriented programming database is one that is congruent with the data defined in object classes and subclasses.
Regardless of the particular architecture, a DBMS can be structured to support a variety of different types of operations for a requesting entity (e.g., an application, the operating system or an end user). Such operations can be configured to retrieve, add, modify and delete information being stored and managed by the DBMS. Standard database access methods support these operations using high-level query languages, such as the Structured Query Language (SQL). The term “query” denominates a set of commands that cause execution of operations for processing data from a stored database. For instance, SQL supports four types of query operations, i.e., SELECT, INSERT, UPDATE and DELETE. A SELECT operation retrieves data from a database, an INSERT operation adds new data to a database, an UPDATE operation modifies data in a database and a DELETE operation removes data from a database.
In commonly assigned U.S. patent application Ser. No. 10/083,075 (the '075 application), filed Feb. 26, 2002 entitled “APPLICATION PORTABILITY AND EXTENSIBILITY THROUGH DATABASE SCHEMA AND QUERY ABSTRACTION”, a framework was disclosed for abstractly viewing physical data. The framework of the '075 application provided a requesting entity (i.e., an end-user or application) with a logical representation of physical data. In other words, the framework of the '075 application provided the requesting entity with a data abstraction model that logically describes an underlying physical data structure. In this way, the requesting entity is decoupled from the underlying physical data to be accessed. Thus, changes to the physical data do not necessitate changes to applications accessing the physical data. Furthermore, abstract queries based on the framework can be constructed without regard for the makeup of the physical data.
Using a data abstraction model according to the framework of the '075 application, abstract queries can be transformed into executable queries capable of being executed against physical data in databases. However, in specific cases a given abstract query can be transformed into more than one executable query dependent on the data abstraction model. For instance, assume a user in a hospital who wants to determine names of patients having had a given blood test with a corresponding result value greater than 200. To this end, the user may specify the following abstract query:                FIND NAME        WHERE RESULT >200However, when dealing in the data abstraction model, the term NAME may refer to more than one physical parameter in the underlying database (e.g., the name of a patient OR a doctor in a medical environment, the name of an employee OR customer in a manufacturing environment, etc.).        
As a result, without further information, the abstract query listed above may be transformed into an executable query that returns the names of the doctors administering tests having the specified results, rather than the patients undergoing the tests (as the user intended). Assume further that the corresponding data abstraction model also allows creating another executable query for the abstract query searching for names of doctors in the hospital having ordered the given blood test with the corresponding result value greater than 200. However, the result sets returned for both executable queries are different. In other words, in order to transform the abstract query into the executable query leading to the user's expected query result, the user's intention at the moment of creation of the abstract query must be taken into consideration.
One approach for dealing with this difficulty can be to create all executable queries which can be created for a given abstract query and to prompt a user to select a corresponding required executable query therefrom. This would, however, jeopardize the decoupling from the underlying physical data, as all executable queries are expressed with respect to an underlying physical data structure. Furthermore, this approach can be confusing for the user and require a deeper understanding of the underlying physical data structure as desired by the user.
Therefore, there is a need for an efficient technique for transforming an abstract query into an executable query when at least two different interpretations of the abstract query are possible.